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ABSTRACT 

The  MDARS  security  robotics  program  has  successfully  demonstrated  the  simultaneous  control  of  multiple  robots 
autonomously  navigating  within  an  industrial  warehouse  environment.  This  real-world  warehouse  system  installation 
required  adapting  a  navigational  paradigm  designed  for  highly  structured  environments  such  as  office  corridors  (with 
smooth  walls  and  regularly  spaced  doorways)  to  a  semi-structured  warehouse  environment  (with  few  walls  and  within 
which  odd-shaped  objects  unpredictably  move  about  from  day  to  day).  A  number  of  challenges,  some  expected  and  others 
unexpected,  were  encountered  during  this  transfer  of  the  system  to  the  test/demonstration  site.  This  paper  examines  these 
problems  (and  others  previously  encountered)  in  the  historical  context  of  the  ongoing  development  of  the  navigation  and 
other  technologies  needed  to  support  the  operations  of  a  security  robotic  system,  and  the  evolution  of  these  technologies 
from  the  research  lab  to  an  operational  warehouse  environment.  A  key  lesson  is  that  a  system’s  robustness  can  only  be 
ensured  by  exercising  its  capabilities  in  a  number  of  diverse  operating  environments,  in  order  to  (1)  uncover  latent  system 
hardware  deficiencies  and  software  implementation  errors  not  manifested  in  the  initial  system  hardware  or  initial 
development  environment;  and  (2)  identify  sensor  modes  or  processing  algorithms  tuned  too  tightly  to  the  specific 
characteristics  of  the  initial  development  environment. 

1.  BACKGROUND:  THE  MDARS  PROJECT  AND  SYSTEM  ARCHITECTURE 

The  Mobile  Detection  Assessment  and  Response  System  (MDARS)  is  a  joint  Army-Navy  development  effort  to  provide  an 
automated  intrusion  detection  and  inventory  assessment  capability  for  use  in  DoD  warehouses  and  storage  sites.  The 
program  is  managed  by  the  Physical  Security  Equipment  and  Management  Office  at  Et.  Belvoir,  VA,  with  overall  technical 
direction  provided  by  the  Naval  Command  Control  and  Ocean  Surveillance  Center,  Research  Development  Test  and 
Evaluation  Division  (NCCOSC  RDTE  DIV,  or  NRaD).  The  MDARS  goal  is  to  provide  multiple  mobile  platforms  that 
perform  random  patrols  within  assigned  areas  in  order  to:  (1)  detect  anomalous  conditions  such  as  flooding  or  fires;  (2) 
detect  intruders;  and  (3)  determine  the  status  of  inventoried  items  through  the  use  of  specialized  RE  transponder  tags.  A 
separate  exterior  development  effort^  addresses  the  requirements  of  outdoor  DoD  storage  sites;  this  paper  is  concerned 
strictly  with  the  MDARS  Interior  system  and  its  operation  in  typical  industrial  warehouse  environments. 

The  design  of  the  MDARS  system  is  driven  by  a  number  of  characteristics  of  the  application  domain:  (1)  MDARS  must 
function  as  a  key  component  of  a  complete  security  system  that  also  includes  fixed  detection  capabilities  and  human 
security  guards;  (2)  the  patrol  coverage  of  a  large  number  (expandable  up  to  32)  of  mobile  robotic  platforms  must  be 
controlled  and  coordinated  to  minimize  opportunities  for  undetected  intrusion,  even  by  insiders;  (3)  both  the  interior 
warehouse  and  exterior  storage  site  environments  require  navigational  capabilities  intermediate  between  those  of  an 
unknown  and  dynamic  environment  (e.g.,  battlefield)  on  the  one  hand,  and  a  completely  structured  and  static  environment 
(e.g.,  hospital  corridors)  on  the  other. 

At  the  highest  level  of  system  description,  the  two  areas  of  the  design  that  particularly  reflect  the  requirements  of  the 
MDARS  application  are:  (1)  the  distribution  of  processing  functionality,  especially  navigational  planning;  and  (2)  the  choice 
of  sensors  and  processing  techniques  to  support  vehicle  navigation  in  the  semi-structured  environments. 

The  mappable  nature  of  the  environment,  the  relatively  low  frequency  of  exception  conditions,  the  need  to  achieve 
coordinated  coverage  of  multiple  platforms,  and  the  requirement  to  simultaneously  support  up  to  32  platforms  suggested  a 
navigation  approach  based  on  centrally  planned  routine  patrol  routes,  with  any  deviations  handled  on  an  exception  basis. 
This  feature  is  implemented  in  MDARS  via  the  Multiple  Robot  Host  Architecture  (MRHA),  in  which  a  LAN  interconnects 
a  Supervisor  computer,  a  pool  of  centrally  located  Planner/Dispatcher  computers,  one  or  more  (human  guard)  Operator 
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Stations,  and  a  Link  Server  (to  route  messages  to  and  from  the  robots  via  RF  modems).  When  a  robot  becomes  idle,  the 
Supervisor  assigns  a  Planner/Dispatcher  from  the  pool  to  plan  and  download  a  new  path.  The  robot  then  autonomously 
executes  the  set  of  commands  until  completion  or  until  an  exception  condition  is  encountered,  whereupon  the  process 
repeats.  Meanwhile,  the  Planner/Dispatcher  is  released  back  to  the  pool  for  allocation  to  another  platform,  so  that  a  small 
number  of  Planner/Dispatchers  can  handle  a  large  number  of  robots.  When  an  event  is  deemed  to  require  the  attention  of  a 
human  operator,  the  Supervisor  assigns  an  Operator  Station,  which  displays  the  appropriate  information  to  the  guard  and 
provides  an  interface  for  command  entry.  Details  of  the  MRHA  architecture  can  be  found  in  recent  papers  by  Everett 
et  al. 

2.  BASELINE  NAVIGATIONAL  CAPABILITIES 

The  navigational  capabilities  of  the  MDARS  Interior  vehicle  build  upon  those  incorporated  in  the  Cybermotion  K2A 
Navmaster  mobility  platform  —  preplanned  virtual  paths  are  downloaded  to  the  platform  for  execution  in  various  possible 
guidance  modes.  Cybermotion’s  virtual  path  planning  has  been  supplemented  in  MDARS  by  NCCOSC-developed 
unrestricted  path  planning.  When  an  obstacle  is  detected  in  the  intended  path  by  the  robot’s  array  of  acoustic  and  infrared 
sensors,  the  robot  halts  and  notifies  the  MDARS  Supervisor  computer,  then  sends  its  history  buffer  of  recent  sensor  data  to 
an  assigned  Planner/Dispatcher,  which  in  turn  uses  it  to  plan  an  alternate  "unrestricted"  path  to  avoid  the  obstacle.  The 
details  of  how  this  process  is  supported  by  the  MRHA  architecture  are  contained  in  the  references.^ 

The  primary  movement  command  in  Cybermotion’s  virtual  path  programming  is  the  RUN  instruction,  which  has  as  its 
arguments  the  coordinates  of  the  desired  destination  and  the  desired  target  speed.  Given  only  the  RUN  instruction,  a  vehicle 
will  turn  toward  the  destination  and  accelerate  to  the  prescribed  speed.  Using  a  ramped  velocity  profile,  the  vehicle  will 
then  slow  in  order  to  reach  a  smooth  stop  at  the 
destination.  (The  derivative  RUNON  command  operates 
like  RUN  except  that  a  smooth  transition  is  made  to  a 
following  RUN  or  RUNON  command,  rather  than 
stopping  at  the  destination.)  A  K2A  platform  with  no 
sensor  will  execute  a  RUN  or  RUNON  solely  through 
odometry:  every  time  the  vehicle  moves  a  fraction  of  an 
inch,  the  algorithm  reads  the  drive  and  steering  encoders, 
calculates  the  relative  translation,  and  updates  the 
vehicle’s  current  position  estimate. 

The  Navmaster  adds  to  the  K2A  mobility  base  a  sensor 
turret  with  RF  data  link,  sonar  system,  and  docking 
beacon.  This  sensor  suite  allows  the  vehicle  to  correct 
its  position  and  heading  estimates  on-the-fly.  This  is 
triggered  by  preceding  a  RUN  or  RUNON  instruction 
with  a  WALL,  HALL,  or  APPROACH  instruction.  The 
WALL  instruction  causes  the  vehicle  to  monitor  the 
relative  range  of  a  WALL  on  either  side  of  the  vehicle 
and  parallel  to  its  intended  path.  As  the  RUN  executes, 
range  points  are  collected  along  the  wall.  If  these  range 
points  fit  a  straight  line  within  programmable  limits, 
corrections  are  made  both  to  the  heading  and  to  the 
position  along  the  axis  perpendicular  to  the  wall.  HALL 
looks  for  walls  on  both  sides  simultaneously. 

APPROACH  corrects  the  vehicle’s  dead-reckoned 
position  as  it  approaches  normal  to  a  wall.  Virtual  paths 
may  be  programmed  in  text,  or  may  be  automatically 

generated  by  drawing  paths  on  a  CAD  map  of  a  Figure  1.  Photograph  of  the  current  MDARS -I  vehicle 
building"^.  configuration  in  the  Camp  Elliott  warehouse  test  site. 


3.  NAVIGATIONAL  ENHANCEMENTS  FOR  THE  WAREHOUSE  ENVIRONMENT 


Cybermotion’s  wall  following  (WALL  and  HALL)  navigational  modes  were  developed  initially  for  environments  similar  to 
office  spaces,  with  many  flat  walls  that  allow  continuous  closed-loop  correction  of  odometric  errors.  Because  the 
warehouse  environments  in  which  MDARS  Interior  will  be  installed  will  not  in  general  have  such  wall  areas,  a 
supplementary  navigational  re-referencing  scheme  is  needed. 


Figure  2.  Map  of  MDARS  Interior  test/demonstration  warehouse  site  at  Camp  Elliott  in  San  Diego,  CA.  Long  storage 
racks  supported  by  posts  are  surrounded  by  rectangles  that  mark  the  boundary  between  the  areas  within  which  storage  items 
may  be  placed  and  the  allowed  robot  (and  forklift)  operating  area  which  includes  the  network  of  interconnected  virtual 
paths. 


Many  different  solutions  have  been  proposed  (and  a  significant  number  actually  implemented)  to  the  problem  of 
determining  a  robot’s  actual  position  within  its  operating  area.  The  approaches  differ  greatly  in  accuracy,  operating  area 
size  and  characteristics,  and  costs  in  terms  of  requirements  for  sensors,  processing,  communications,  and  installation 
complexity.  Typically  some  sensor  is  used  to  measure  either  the  distance  and/or  the  bearing  to  some  chosen  objects  in  the 
environment.  Objects  with  desirable  characteristics  may  be  deliberately  emplaced  at  surveyed  locations,  or  existing  objects 
may  be  used  opportunistically.  The  objects  may  participate  in  the  sensing  process  either  actively  or  passively.  The  sensing 
system  may  involve  ultrasonics,  visible  or  IR  light,  or  RF.  Here  are  a  few  examples: 

•  An  ultrasonic  vehicle  location  system^  developed  at  Tulane  University  employs  a  transmitting  ultrasonic  transducer 
mounted  on  the  vehicle  (a  TRC  Labmate  is  currently  used)  and  a  geometric  array  of  receiving  transducers  mounted  on 
the  ceiling  of  the  robot's  9  foot  by  12  foot  operating  area.  Sophisticated  envelope-peak  phase  detection  and 
compensation  for  temperature  and  humidity  variations  provide  a  .001  inch  position  accuracy  at  100  Hz. 

•  Harris  Technologies'  Infogeometric  System^  employs  a  network  of  intelligent  code-division-multiple-access  (CDMA) 
spread  spectrum  RF  devices  (both  mobile  users  and  fixed  reference  units)  that  self-organize  in  order  to  provide  data 
communications  and  distributed  sensor  data  fusion  as  well  as  associative  location  and  orientation  tracking  and  network 
level  autocalibration.  The  navigation  function  is  essentially  analogous  to  a  scaled-down  Loran  system. 

•  MacLeod  Technologies'  CONAC  System^  employs  a  vehicle-mounted  laser  spinning  at  3000  rpm  and  an  array  of 
photosensors  fixed  at  known  locations.  The  precise  times  of  laser  beam  detection  are  then  centrally  processed  to  yield 
vehicle  position  and  heading  at  a  25  Hz  rate,  with  sub-cm  accuracy.  This  scheme  has  been  demonstrated  controlling 
both  an  RC  toy  car  in  a  parking  lot  and  a  Dodge  Caravan  traveling  down  a  highway  at  50  mph  (not  at  the  same  time). 

Everett^  provides  a  comprehensive  overview  of  acoustical,  optical,  and  RF  position-location  techniques  and  available 
systems. 


The  navigational  re-referencing  technique  implemented  on  the  MDARS  Interior  vehicles,  lateral  post  detection,  is  a  hybrid 
scheme  combining:  (1)  IR  proximity  sensors  that  determine  the  presence  of  a  cooperative  target  of  known  location  at  a 
precisely  determined  bearing,  with  (2)  ultrasonic  range  sensors  that  determine  the  distance  to  the  object.  The  scheme  is 
inexpensive  in  terms  of  both  sensor  hardware  and  processing  power  requirements,  and  fits  smoothly  into  the  Cybermotion 
virtual  path  planning  structure.^ 

Short  vertical  stripes  of  1-inch  retroreflective  tape  are  mounted  on  various  immobile  objects  (usually  structural  support 
posts)  on  either  side  of  a  virtual  path  segment.  The  X-Y  locations  of  these  tape  markers  are  encoded  into  the  virtual  path 
program  as  parameters  (distance  along  the  path  where  the  stripe  should  be  detected,  and  lateral  distance  expected  from  path 
to  stripe)  for  a  new  STRIPE  navigational  mode  implemented  by  Cybermotion  on  the  Navmaster  robot.  Installation  of  the 
tape  takes  only  seconds,  and  there  is  little  chance  of  damage  to  the  unobtrusively  flat  tape  from  passing  forklifts. 

A  Banner  Engineering  Q85VR3LP  retroreflective  IR  proximity  sensor  is  mounted  on  each  side  of  the  Navmaster’s  turret, 
pointed  perpendicular  to  the  robot’s  direction  of  travel.  As  the  robot  passes  the  stripe,  the  sensor  triggers  a  "snapshot" 
virtual  path  instruction  that  records  the  current  side-sonar  range  values.  The  longitudinal  position  of  the  platform  is  updated 
to  the  known  marker  coordinate,  while  lateral  position  is  inferred  from  the  sonar  data,  assuming  that  both  values  fall  within 
specified  tolerances.  Eigure  3  depicts  the  geometry  of  the  scheme  in  operation. 


Retro-reflective 

Markers 


Eigure  3.  Circularly  polarized  retroreflective  proximity  sensors  are  used  to  locate  vertical  strips  of  retroreflective  tape 
attached  to  shelving  support  posts  in  the  Camp  Elliott  warehouse  installation  of  the  MDARS  security  robot. 

The  accuracy  of  the  longitudinal  (marker)  correction  is  much  higher  than  that  of  the  lateral  sonar  readings,  since  the 
circularly  polarized  Banner  sensor  responds  only  to  the  presence  of  a  retroreflector  and  ignores  reflections  from  even  highly 
specular  surrounding  surfaces,  while  the  ultrasonic  energy  from  the  sonar  will  echo  back  from  any  reflective  surface 
encountered  by  its  relatively  wide  beam.  While  protruding  objects  in  the  vicinity  of  the  tape  (not  unexpected  in  a 
warehouse  environment)  result  in  a  shorter  measured  lateral  range  value,  the  long-term  effect  on  X-Y  bias  tends  to  be 
averaged  out. 

This  lateral  post  referencing  concept  was  implemented  on  the  MDARS  unit  in  May  1994  and  tested  in  an  operational 
warehouse  environment  at  Camp  Elliott  in  San  Diego,  CA.  The  Navmaster  robot  was  run  continuously  back  and  forth  along 
a  150  foot  path,  with  7  tape  markers  set  on  posts  20  feet  apart.  No  other  navigational  referencing  instructions  were 
contained  in  the  path  program.  Initial  heading  and  location  errors  were  quickly  nulled  out  after  the  second  or  third  post  was 
detected,  and  accumulated  errors  remained  essentially  insignificant  for  the  remaining  length  of  the  path.  Each  time  the 
robot  reversed  course  at  the  end  of  a  run,  some  noticeable  heading  error  was  introduced,  but  the  error  was  then  quickly 


eliminated  as  lateral-post  updates  were  processed  on  the  return  leg.  Introduction  of  objects  protruding  as  much  as  16  inches 
into  the  aisle  immediately  adjacent  to  the  retroflective  tape  caused  the  expected  shift  in  the  actual  path  followed,  but 
introduced  no  instabilities  in  the  overall  path-following  process. 

4.  A  NEW  ENVIRONMENT  BRINGS  "NEW"  PROBLEMS 


The  transfer  of  the  lateral  post  scheme  to  Camp  Elliott  was  not  immediately  successful,  however.  Several  completely 
unanticipated  and  unrelated  problems  appeared  during  initial  testing  at  the  warehouse,  even  after  complete  subsystem 
checkout  and  integration  in  the  laboratory.  In  this  section  we  will  place  these  problems  in  the  historical  context  of  other 
issues  encountered  while  moving  a  robot  to  a  new  operating  environment,  over  more  than  a  decade  of  development  of 
MDARS  and  its  precursor  security  robots,  ROBART  I  and  ROBART  II. 

4.1  Pre-MDARS  security  robot  development 

Generally  regarded  as  the  world’s  first  autonomous  security  robot,  ROBART  I  was  developed  in  1982  at  the  Naval 
Postgraduate  School^.  While  rich  in  collision  avoidance  sensors,  this  research  platform  had  no  sense  of  its  absolute 
location,  and  was  thus  strictly  limited  to  navigating  along  reflexive  patrol  routes  defined  by  the  relative  locations  of 
individual  rooms,  while  periodically  returning  to  a  recharging  station  by  homing  on  an  IR  beacon. 


The  second-generation  follow-on  to  ROBART  I  was 
ROBART  II  (figure  4),  which  incorporated  a  multiprocessor 
architecture  and  augmented  sensor  suite  in  order  to  support 
enhanced  navigation  and  security  assessment  capabilities. 
The  addition  of  a  world  model  allowed  ROBART  II  to:  (1) 
determine  its  location  in  world  coordinates,  (2)  create  a  map 
of  detected  obstacles  and  (3)  better  perform  multisensor 
fusion  on  the  inputs  from  its  suite  of  security  and 
environmental  sensors.^®  ROBART  II  was  transfered  to 
NRaD  (then  NOSC)  in  1986,  and  used  as  a  testbed  for  the 
development  of  obstacle  mapping  and  other  sensor  fusion 
and  navigation  capabilities. 

Problem:  When  ROBART  II  was  first  moved  from  a  small 
laboratory  space  to  a  large  test  bay  in  January  1990,  a 
software  data  conversion  rollover  error  that  occurred 
whenever  the  sonar  range  was  greater  than  34  feet  was 
uncovered.  This  software  flaw  had  lain  undetected  for  over 
3  years,  even  under  heavy  use,  due  to  the  constricted 
confines  of  the  original  lab  space.  When  the  problem  finally 
did  manifest  itself,  the  true  nature  of  the  bug  was  not 
correctly  analyzed  until  after  several  other  suspected  causes 
were  systematically  eliminated:  low  battery  voltage, 
electrical  supply  noise,  acoustic  interference  between  sensor 
transducers,  and  even  confusion  by  chirping  crickets. ^  ^ 

Problem:  When  ROBART  II  was  later  relocated  to  a  new 
laboratory  building  in  mid  1993,  the  performance  of  its 
reflexive  teleoperation  mode^^  (in  which  a  human  operator’s 
teleoperation  inputs  are  modulated  by  inputs  from  collision 
avoidance  and  other  sensors)  was  observed  to  be 
substantially  degraded:  the  robot  would  approach  much 
closer  than  intended  to  a  wall  before  turning  away.  This 
problem  occurred  because  the  surface  of  the  wall  of  the  new 


Figure  4.  ROBART  II.  Second  generation  security  robot 
constructed  between  1982  and  1986. 


laboratory  had  much  less  texture  than  that  of  the  space  in  which  the  behavior  had  been  developed  and  tuned;  the  reduction 
in  diffuse  reflection  meant  the  ultrasonic  and  near-lR  sensors  employed  did  not  detect  the  presence  of  the  wall  until  it  was 
much  closer. 

4.2  MDARS  -  laboratory  experience 

Beginning  in  1989,  the  security  robotics  technology  base  developed  on  the  ROBART  testbeds  was  transitioned  to  the 
MDARS  Interior  engineering  development  effort.  Obstacle  detection  sensors  and  unrestricted  path  planning  algorithms 
that  permit  a  robot  to  avoid  collisions  and  to  automatically  move  around  detected  obstacles  were  ported  to  the  Cybermotion 
K2A  Navmaster  robot. 

Problem:  An  array  of  ultrasonic  sensors  aligned  7  degrees  below  the  horizontal  was  incorporated  to  detect  obstacles  on  the 
floor  in  front  of  the  robot.  When  this  system  was  delivered  to  another  government  laboratory  for  test  and  evaluation,  it  was 
discovered  that  sonar  returns  from  harmless  expansion  joints  in  the  concrete  floor  were  being  misinterpreted  as  obstacles; 
the  smoother  floor  of  the  original  lab  space  had  resulted  in  completely  specular  reflection.  The  solution  was  to  fabricate 
new  mounting  plates  for  the  sensor  array,  eliminating  the  downward  pitch.  While  this  simple  relocation  of  the  transducers 
effectively  eliminated  the  problem  of  spurious  returns  from  the  floor  cracks,  it  also  reduced  the  robot’s  capability  to  detect 
low-lying  obstructions. 

4.3  MDARS  -  warehouse  experience 

We  return  now  to  the  1994  installation  of  MDARS  in  the  warehouse  at  Camp  Elliott. 

Problem:  Following  complete  checkout  in  the  MDARS  development  laboratory  at  NRaD,  the  lateral  post  detection 
software  was  ported  to  another  Navmaster  platform  at  the  Camp  Elliott  warehouse  site.  It  turned  out  that  this  robot’s 
mobility  base  was  not  well  aligned,  so  that  its  execution  (with  no  sensor  input  except  odometry)  of  a  RUN  command 
deviated  significantly  from  a  straight  line,  by  as  much  as  1.5-2  feet  over  a  travel  distance  of  20  feet  (Cybermotion  calls  this 
precession).  This  hardware  problem  had  not  been  previously  detected  because,  in  wall-following  (WALL)  mode,  the  robot 
used  a  steady  stream  of  wall-distance  measurements  to  constantly  correct  the  error.  Because  the  lateral  post  detection 
method  used  only  intermittent  fixes  to  correct  the  odometry-derived  position  estimate,  the  fact  that  the  robot  failed  to  hold  a 
constant  heading  resulted  in  a  lateral  divergence  that  eventually  became  so  large  the  displacement  exceeded  the  range  of  the 
proximity  sensor,  and  the  platform  subsequently  became  "lost."  This  problem  was  of  course  easily  solved  by  employing  a 
properly  calibrated  mobility  base. 

Problem:  One  completely  unexpected  development  was  that  the  warehouse  exhibited  several  locations  where  the  RE 
communications  link  between  the  robot  and  control  station’s  Link  Server  became  very  unreliable.  Systematic  mapping  of 
RE  signal  levels  indicated  wide  variation,  including  areas  of  very  low  signal  strength  (see  figure  5).  When  the  robot  entered 
one  of  these  RE  nulls,  the  Arlan  RE  units  (which  provide  the  user  with  a  9600-bps  serial  channel,  using  transparent 
packetization,  error  detection,  and  retransmission)  would  automatically  retransmit  packets  until  they  got  through.  This 
retransmission  was  transparent  to  the  higher  level  processing,  except  that  the  higher  level  protocol’s  one-second  timeout 
would  occasionally  be  exceeded,  resulting  in  the  retransmission  of  a  complete  message.  Because  the  character-oriented 
data  stream  was  protected  by  only  a  simple  8-bit  checksum,  the  higher  level  processing  would  occasionally  accept 
improperly  combined  message  fragments  as  a  valid  message,  resulting  in  the  trashing  of  various  status  bits  (incorrectly 
indicating  a  low  battery  condition,  presence  of  an  intruder,  a  fire  alarm,  etc.).  In  one  case,  a  minor  communications  error 
led  the  system  to  initiate  a  sequential  interrogation  of  2000  nonexistent  inventory  tags.  This  problem  has  been  addressed  by 
moving  to  a  greater  bandwidth  Arlan  RE  Ethernet  implementation  and  a  more  robust  CRC  in  the  higher  level  protocol. 

Problem:  Improper  alignment  of  individual  LEDs  in  the  IR  docking  beacon  on  the  robot  resulted  in  a  small  gap  in  the 
intended  180-degree  beam  coverage.  Since  the  docking  software  was  written  with  the  assumption  that  an  interruption  of 
the  beam  meant  a  person  was  blocking  the  path,  it  waited  for  the  person  to  move  out  of  the  way  —  in  this  case  indefinitely. 
The  LED-alignment  problem  had  not  been  detected  in  the  laboratory  because  the  robot  had  never  approached  the  beacon 
from  the  "gap"  angle  (i.e.,  the  robot  was  always  within  a  smaller  ellipsoid  of  uncertainty  when  it  initiated  a  docking  action). 
This  problem  was  solved  by  realigning  the  beacon  to  eliminate  the  gap  in  its  coverage. 
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Figure  5.  Survey  of  RF  signal  levels  measured  in  Camp  Elliott  warehouse. 

Problem;  The  IR  docking  beacon  at  Camp  Elliott  was  initially  installed  near  a  west-facing  exterior  doorway.  It  was  soon 
discovered  that  the  late  afternoon  sun  completely  saturated  the  photodetectors  used  in  the  docking  process,  and  the  docking 
station  had  to  be  moved.  All  previous  charger  locations  in  the  development  environment  had  been  along  interior  walls  free 
of  optical  interference. 

Problem:  Because  it  was  recognized  from  the  beginning  that  MDARS  robots  would  have  to  share  their  warehouse 
operations  area  with  forklift  operators  and  other  human  workers,  reasonable  precautions  were  taken  to  prevent  accidents. 
Whenever  a  robot  approaches  the  passageway  between  the  two  bays  (see  figure  2),  a  flashing  light  mounted  in  a  highly 
visible  location  above  the  door  is  activated  to  alert  forklift  operators  who  might  be  working  nearby.  Unfortunately,  human 
operators  do  not  necessarily  heed  such  warnings;  in  fact,  in  October  1994,  a  speeding  forklift  operator  spilled  his  entire  load 
in  an  emergency  stop  that  narrowly  avoided  a  collision  with  a  robot  approaching  from  the  "blind"  alley  to  his  right.  The 
virtual  path  structure  within  the  warehouse  has  now  been  edited  to  prohibit  the  robot  from  approaching  this  virtual  node 
from  the  side  corridors,  thus  assuring  that  the  forklift  driver  can  see  the  robot  directly  ahead  as  it  makes  its  way  towards  him 
down  the  central  corridor. 


5.  DISCUSSION  AND  LESSONS  LEARNED 


5.1  General  lessons  learned 

Our  purpose  in  enumerating  these  problems  is  to  point  out  that  the  process  of  moving  a  mobile  robotic  system  from  one 
operating  environment  to  another,  especially  when  moving  from  a  deliberately  benign  laboratory  development  environment 
to  a  more  complex  and  less  structured  environment  more  representative  of  real-world  operations,  is  one  in  which 
unanticipated  problems  are  the  rule  rather  than  the  exception.  The  causes  of  the  problems  described  above  fit  into  a  number 
of  different  categories: 

•  Hardware  deficiencies  not  manifested  on  the  initial  system  hardware; 

•  Hardware  deficiencies  not  manifested  in  the  initial  development  environment; 

•  Software  implementation  errors  not  manifested  on  the  initial  system  hardware; 

•  Software  implementation  errors  not  manifested  in  the  initial  development  environment; 

•  Sensor  modes  or  processing  algorithms  tuned  too  tightly  to  specific  characteristics  of  the  initial  development 
environment;  and 

•  Subtle  interactions  between  multiple  hardware  and  software  components,  leading  to  unexpected  breakdowns. 

While  a  human's  perceptual  capabilities  are  powerfully  adept  at  characterizing  both  the  similarities  and  differences  between 
various  features  of  his/her  environment  —  at  detecting  both  the  general  rule  and  the  specific  exception  to  it  —  a  robot's 
sensory  inputs  are  far  more  limited,  and  it  can  interpret  these  inputs  only  up  to  the  limits  of  its  model  of  its  environment. 

A  robot's  software  implicitly  embodies  a  world  model  derived  from  —  but  infinitely  simpler  than  —  the  world  model  present 
in  the  mind  of  the  software  designer.  The  designer  may  deliberately  work  to  capture  certain  specific  aspects  of  the  world  in 
the  robot's  "brain,"  while  other  aspects  may  creep  in  as  unintended  consequences  of  various  software  design  decisions. 
Some  problems  arise  when  the  robot's  implicit  world  model  is  not  rich  enough  to  support  the  behaviors  required  by  the 
application.  Many  others  result  when  the  designer  simply  fails  to  understand  the  limits  of  his  robot's  world  model  —  which 
aspects  of  his  own  world  model  have  been  implanted  in  the  robot,  and  which  have  not.  If  a  complex  robotic  system  is  to 
operate  robustly,  the  model  must  take  adequate  account  of  the  relevant  dimensions  of  variability  of  the  environment,  as  they 
will  be  reported  by  the  sensor  subsystems.  A  rough  floor  is  still  a  floor,  and  you  can  drive  over  it;  a  low-lying  obstacle  is 
still  an  obstacle,  and  you  can't  drive  over  it.  The  sensors  and  perceptual  software  that  build  a  robot's  world  model  have  to  be 
able  to  draw  such  distinctions. 

Well-implemented  adaptive  behavior  in  a  robot  (such  as  Cybermotion's  wall-following  mode)  can  bring  along  the  downside 
risk  of  actually  masking  a  hardware  or  software  fault  that  may  then  manifest  itself  later  at  an  unfortunate  time.  One 
possible  solution  to  this  problem  is  to  instrument  adaptive  behaviors  in  order  to  monitor  their  adaptation  modes  —  to  install 
"intelligence"  analogous  to  that  of  the  human  driver  who,  while  driving  straight  down  the  highway,  notes  the  fact  when  his 
car's  steering  constantly  "pulls  left."  Cybermotion  is  currently  in  the  process  of  doing  just  that  with  their  closed-loop 
navigation  modes. 

Behavioral  robustness  is  required  if  mobile  robots  are  to  find  viable  markets.  Robots  must  be  mass  producible,  rather  than 
handcrafted,  and  they  must  function  acceptably  over  as  wide  a  range  of  environments  as  possible  without  excessive  manual 
tuning.  Thus  the  designer  of  mobile  robot  hardware  and  software  must  accommodate  the  full  range  of  variability  within 
manufacturing  processes  and  within  target  operating  environments. 


5.2  Specific  lessons  for  MDARS 


The  MDARS  Interior  system  is  currently  slated  to  be  installed  at  an  operational  DoD  warehouse  for  Early  User  Evaluation 
(EUE)  in  late  1996.  Based  on  our  previous  experiences  in  transfering  ROB  ART  and  MDARS  robots  to  new  environments, 
as  described  above,  it  is  clearly  prudent  to  anticipate  that  yet  additional  problems  will  be  encountered  in  navigating  the 
robot  through  this  new  warehouse.  It  makes  sense  to  try  to  identify  strategies  that  can  reduce  the  technical,  schedule,  and 
cost  risks  to  the  MDARS  program  as  the  system  is  installed  at  the  EUE  location.  Eor  example: 

•  Carefully  survey  the  site  in  advance  of  installation  in  order  to  identify  environmental  factors  that  might  affect 
navigational  performance.  Are  the  posts  supporting  the  storage  racks  30  feet  apart  instead  of  20?  What  are  the 
reflective  characteristics  of  floors  and  walls  to  both  ultrasonic  and  IR?  Do  the  standard  operating  practices  of  the 
human  co-workers  seem  to  pose  any  special  challenges? 

•  Exercise  the  MDARS  system  in  as  many  diverse  environments  as  possible  prior  to  EUE,  in  order  to  detect  and  correct 
additional  latent  flaws  before  moving  to  the  EUE  site. 

•  Anticipate  that,  despite  our  best  efforts,  real-time  navigational  re-referencing  along  the  patrol  route  may  occasionally 
fail,  resulting  in  the  robot  becoming  lost.  Develop  in  response  a  general  purpose  automatic  procedure  that  can  be 
executed  in  order  to  re-establish  the  robot's  absolute  position. 

The  basic  approach  for  such  a  navigational  recovery  procedure  can  be  easily  outlined,  as  follows.  Start  with  the  recognition 
that  the  robot  can't  get  too  lost  over  a  relatively  short  period  of  time  (i.e.,  it  may  be  disoriented  to  the  extent  it  cannot 
complete  the  assigned  virtual  path,  but  its  position  is  still  within  some  bounded  ellipsoid  of  uncertainty).  Starting  with  this 
knowledge  of  the  robot's  approximate  position,  the  semi-structured  nature  of  the  warehouse  aisles  can  be  exploited  to  effect 
a  recovery  maneuver.  Eor  example,  a  static  interpretation  of  surrounding  sonar  data  can  be  used  to  generate  a  preliminary 
move  to  the  perceived  center  of  the  aisle.  Reflexive  "tunnel  navigation"  can  then  be  invoked  to  cautiously  maneuver  the 
platform  along  the  longitudinal  axis  of  the  aisle  at  reduced  speed  while  searching  for  definitive  reference  landmarks. The 
robot's  actual  heading  and  X-Y  position  remain  ambiguous  during  this  maneuver,  but  the  onboard  sonars  can  be  used  to 
keep  the  platform  generally  centered  between  the  perceived  clutter  on  either  side  of  the  aisle. 

Magnetic  heading  from  an  inexpensive  fluxgate  compass  can  potentially  aid  this  process,  and  in  worst-case  scenarios  ensure 
the  robot  is  moving  down  the  aisle  in  the  desired  direction.  Retroreflective  stripe  markers  would  then  be  processed  in 
conventional  fashion  to  re-reference  the  platform,  assuming  the  corrupted  dead-reckoning  solution  is  not  off  by  more  than 
the  typical  20-foot  stripe-separation  distance.  A  more  robust  (and  expensive)  sensing  approach  would  involve  a  rotating 
laser  scanner  to  detect  in-plane  retroreflective  targets,  the  advantage  being  a  more  tolerant  acceptance  window  due  to  longer 
effective  range  and  the  360-degree  field-of-view.  If  laser  range  information  is  subsequently  available,  triangulation 
techniques  could  also  be  used  to  establish  actual  platform  heading  and  position.  Yet  a  third  possible  alternative  would 
involve  reflexive  aisle  transit  to  the  first  encountered  intersection,  followed  by  a  static  ultrasonic  position-location  action 
using  the  four  corner  shelf-support  posts  as  definitive  targets. 

5.3  Coexistence  of  mobile  robots  and  manned  vehicles 

The  large  number  of  robots  performing  industrial  tasks  such  as  welding,  painting,  and  spraying  in  operational  factory 
environments  has  generated  a  base  of  experience  in  the  coexistence  of  human  factory  workers  and  industrial  manipulators. 
The  key  concern  with  a  powerful  manipulator  is  the  safety  of  workers  entering  its  workspace  to  perform  tasks  such  as 
feeding  materials;  fortunately,  the  limits  of  the  workspace  are  static  and  access  can  be  easily  controlled.  Eor  mobile  robots, 
on  the  other  hand,  the  workspace  is  neither  static  nor  (in  many  cases)  physically  constrained.  While  a  robot  mailcart 
equipped  with  good  bumpers  repeatedly  following  an  installed  guidepath  at  1  mph  does  not  pose  a  significant  threat  to  the 
safety  of  the  people  walking  the  corridor  (nor  do  they  pose  a  threat  to  it),  the  initial  MDARS  experience  demonstrates 
vividly  that  a  larger,  heavier  mobile  security  robot  autonomously  patrolling  a  warehouse  in  which  potentially  inattentive 
forklift  operators  are  moving  quickly  about  poses  issues  of  safety  for  the  robot  as  well  as  for  the  humans  involved. 


Beyond  simple  safety,  the  activities  of  humans  in  the  warehouse  unpredictably  reconfigure  the  robot’s  environment  as 
cartons  and  pallets  are  moved  about  daily,  somewhat  complicating  the  navigation  task  and  making  the  role  of  the  MDARS 
operator  (guard)  all  the  more  important  as  the  assessment  engine  of  last  resort.  Finally,  the  need  to  cultivate  acceptance  of 
robots  by  human  co-workers  is  clear  if  they  are  to  operate  successfully  in  the  same  space,  since  any  seriously  adversarial 
situation  between  robot  and  human  co-worker  will  eventually  be  manifested  as  a  system  malfunction. 

6.  SUMMARY 

Transplanting  a  mobile  robot  system  from  the  benign  laboratory  environment  in  which  it  was  initially  developed  to  a  semi- 
structured  test  and  demonstration  environment  is  seen  to  be  a  challenging  process,  but  one  which  is  necessary  for  the 
successful  development  and  validation  of  robust  navigational  capabilities.  The  MDARS  Interior  security  robot  system  has 
successfully  made  this  transition  as  the  latest  in  a  series  of  steps  that  will  eventually  see  it  performing  security  patrols  in 
operational  DoD  warehouses.  The  lessons  learned  to  date  will  be  exploited  to  improve  the  chances  of  success  as  the 
MDARS  system  is  transfered  to  successively  more  demanding  environments. 
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